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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The present document is part 3 of a multi-part deliverable covering Satellite Earth Stations and Systems (SES); 
Satellite Component of UMTS/IMT-2000; Multimedia Broadcast/Multicast Services, as identified below: 

Parti: "Services definitions"; 

Part 2: "Architecture and functional description"; 

Part 3: "Introduction in the Radio Access Network (RAN)"; 

Part 4: "Interworking with terrestrial UMTS networks"; 

Part 5: "Performances over the radio interface"; 

Part 6: "Security". 
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Introduction 

S-UMTS stands for the Satellite component of the Universal Mobile Telecommunication System. S-UMTS systems will 
complement the terrestrial UMTS (T-UMTS) and inter-work with other IMT-2000 family members through the UMTS 

core network. S-UMTS will be used to deliver 3^^" generation mobile satellite services (MSS) utilizing either low (LEO) 
or medium (MEO) earth orbiting, or geostationary (GEO) satellite(s). S-UMTS systems are based on terrestrial 3GPP 
specifications and will support access to GSM/UMTS core networks. 

NOTE 1 : The term T-UMTS will be used in the present document to further differentiate the Terrestrial UMTS 
component. 

Due to the differences between terrestrial and satellite channel characteristics, some modifications to the terrestrial 
UMTS (T-UMTS) standards are necessary. Some specifications are directly applicable, whereas others are applicable 
with modifications. Similarly, some T-UMTS specifications do not apply, whilst some S-UMTS specifications have no 
corresponding T-UMTS specification. 

• Since S-UMTS is derived from T-UMTS, the organization of the S-UMTS specifications closely follows the 
original 3™ Generation Partnership Project (3GPP) structure. 

An S-UMTS system is defined by the combination of a family of S-UMTS specifications and 3GPP specifications, as 
follows: 

• If an S-UMTS specification exists it takes precedence over the corresponding 3GPP specification (if any). 
This precedence rule applies to any references in the corresponding 3GPP specifications. 

NOTE 2: Any references to 3GPP specifications within the S-UMTS specifications are not subject to this 
precedence rule. For example, an S-UMTS specification may contain specific references to the 
corresponding 3GPP specification. 

• If an S-UMTS specification does not exist, the corresponding 3GPP specification may or may not apply. The 
exact applicability of the complete list of 3GPP specifications shall be defined at a later stage. 
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Scope 



The present document specifies the support of Multimedia Broadcast/Multicast Service in S-UMTS, based on a point to 
multipoint connection, either directly from satellite or via terrestrial repeaters (IMRs). 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

[1] ETSI TS 125 346 (Release 6): "Universal Mobile Telecommunications System (UMTS); 

Introduction of the Multimedia Broadcast/Multicast Service (MBMS) in the Radio Access 
Network (RAN); Stage 2 (3GPP TS 25.346 Release 6)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 125 346, Release 6 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Access Stratum 

BCCH Broadcast Control CHannel 

CBS Cell Broadcast Service 

CCCH Common Contiol CHannel 

CN Core Network 

CRNC Conti-olling Radio Network Controller 

DRNC Drift Radio Network Control 

DTCH Dedicated Traffic CHannel 

EACH Forward Access CHannel 

ELC Frequency Layer Convergence 

ELD Frequency Layer Dispersion 

IMR Intermediate Module Repeater 

LCI Layer Convergence Information 

MAC Medium Access Conti'ol 

MCCH S-MBMS point-to-multipoint Control Channel 

MICH S-MBMS notification Indicator Channel 

MSCH S-MBMS point-to-multipoint Scheduling Channel 

MTCH S-MBMS point-to-multipoint Traffic Channel 
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NAS Non Access Stratum 

NI Notification Indicator 

PDCP Packet Data Convergence Protocol 

PDCP Packet Data Convergence Protocol 

PHY PHYsical 

PLMN Public Land Mobile Network 

PTM Point-To-Multipoint 

ptp point-to-point 

QoS Quality of Service 

RA Registration Area 

RAB Radio Access Bearer 

RACH Random Access Channel 

RAN Radio Access Network 

RB Radio Bearer 

RLC Radio Link Control 

RNC Radio Network Control 

RNS Radio Network Sub-system 

RRC Radio Resource Control 

S-CCPCH Secondary-Common Control Physical Channel 

SGSN Serving GPRS Support Node 

S-MBMS SatelHte-Multimedia Broadcast Multicast Service 

SRNC Serving Radio Network Control 

TCTF Transport Channel Type Field 

TFC Transport Format Combination 

UE User Equipment 

UM Unacknowledged Mode 

URA UMTS Radio Access 

USRAN UMTS Satellite Radio Access Network 



4 USRAN requirements and constraints 

4.1 Requirements inherited from 3GPP 
4.1 .1 Requirements for the support of S-MBMS 

The requirements inherited from 3GPP for the support of S-MBMS are: 

1) S-MBMS data transfer shall be downlink only. 

2) QoS attributes shall be the same for S-MBMS Multicast and Broadcast modes. 

3) During S-MBMS data transmission it shall be possible to receive paging messages from both satellite and 
terrestrial networks. 

4) Simultaneous reception of S-MBMS and non-S-MBMS services shall depend upon UE capabilities. 

5) Simultaneous reception of more than one S-MBMS services shall depend upon UE capabilities. 

6) A notification procedure shall be used to indicate the start of S-MBMS data transmission. This procedure shall 
contain S-MBMS Radio Bearer information. 

7) S-MBMS UE multicast activation (Joining) and broadcast subscription shall be transparent to USRAN. 

8) Reception of S-MBMS shall not be guaranteed at RAN level. S-MBMS does not support individual 
retransmissions at the radio link layer, nor does it support retransmissions based on feedback from individual 
subscribers at the radio level. This does not preclude the periodic repetitions of the S-MBMS content based on 
operator or content provider scheduling or retransmissions based on feedback at the application level. 

9) A mechanism to provide USRAN the received QoS per UE is not required as part of S-MBMS. 
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10) UE controlled "service based" spot/IMR cell selection/reselection shall not be permitted. 

11) In the case of USRAN only, guaranteed "QoS" linked to a certain initial downlink power setting is not 
required. 

12) S-MBMS charging should be transparent to the RAN. 

13) S-MBMS should allow for low UE power consumption. 

14) Header compression should be used. 

4.1.2 S-MBMS Notification Requirements 

The requirements inherited from 3GPP for notification are: 

1) S-MBMS notification shall be transmitted within the S-MBMS service area. 

2) S-MBMS notification shall be sent so it could be received by all UEs with an activated S-MBMS service, 
regardless of their RRC state or the lack of an RRC connection. 

3) S-MBMS notification should maximize the reuse of existing channels. 

4) S-MBMS notification should allow terminals to minimize their power consumption, meaning that UEs with an 
activated S-MBMS service should not listen permanently, but at regular intervals to S-MBMS notification. 

5) Reception of S-MBMS notification cannot be guaranteed. 

6) UEs may receive S-MBMS notification and simultaneously monitor other occasions, e.g. UE dedicated paging 
and CBS messages, paging from terrestrial network. The avoidance of collisions cannot be guaranteed. If 
collisions occur, the UE dedicated Paging has higher priority (UE requirement). Paging from terrestrial 
networks has highest priority. 

4.2 Requirements specific to satellite 

4.2.1 PLMN Id 

PLMN Id in System Information broadcast over BCH is related to the country where satellite Hub is installed. 

4.2.2 Dual mode UE 

Dual mode UE shall be configurable to define the priority RAN. 

In case UE is configured for terrestrial RAN first priority, S-MBMS shall not degrade terrestrial services. 

UE behaviour is as if it camps over two cells, the terrestrial cell and the satellite spot. 

For dual mode UE implementing two separate receiver chains, synchronization with both terrestrial and satellite 
systems shall be maintained in parallel. 

For dual mode UE implementing single receiver chain, synchronization with both terrestrial and satellite systems is 
sequential, i.e. UE restarts synchronization acquisition procedure when switching reception form one system to the 
other. 
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5 S-MBMS USRAN and Protocol Architecture 

5.1 S-MBMS USRAN Architecture Principles 
5.1 .1 S-MBMS Service Context in CRNC 

Each RNC-which is controlling one or several spots/IMR cells within an S-MBMS Service area maintains an S-MBMS 
Service Context for each S-MBMS service. 

1) Each CRNC S-MBMS Service Context is associated with an S-MBMS service ID. 

2) For multicast service, the CRNC S-MBMS Service Context contains a list of PMM connected mode UEs 
which are present in one or several spots/IMR cells of the CRNC and which have activated an S-MBMS 
service. The list includes at least the U-RNTI of the UEs. 

3) The S-MBMS Service Context is created in the CRNC either: 

if the SGSN informs the RNC that a UE has activated the S-MBMS Service in a cell controlled by the 
CRNC by the UE Linking procedure. In this case, the CRNC is the SRNC of the UE; or 

if the RNC is notified of an S-MBMS Session Start; 

or if the RNC serves as a Drift RNC for a PMM-CONNECTED UE and receives for this UE a UE Link 
from the SRNC containing the S-MBMS Service Id of the concerned S-MBMS Service. 

4) Each RNC which is informed by the SGSN that a UE has activated one (or several) S-MBMS Service(s) by 
the UE Linking procedure maintains an S-MBMS Context for each indicated S-MBMS service, irrespectively 
of the S-MBMS Service Area. 

5) The S-MBMS Service Context is released by the CRNC either: 

if the S-MBMS Service Context does not contain any UE information after a UE Unlinking procedure 
from a SGSN and there is no active S-MBMS Session for the concerned S-MBMS Service; or 

if the S-MBMS Service Context does not contain any UE Link at the time of a Session Stop; or 

if the RNC receives a CN De-Registration for S-MBMS Service. 

6) Associated functionalities: 

Bearer type selection for S-MBMS transmissions based on information in the CRNC S-MBMS Service 
Context. The decision process requires inter-working with Radio Resource Management and with the 
UE's SRNC in the case of ptp bearers. 

S-MBMS RB control for ptm bearers in each cell, based on information in the CRNC S-MBMS Service 
Context. 

Update of the S-MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
S-MBMS Service, has entered a cell. Update of the S-MBMS Service Context via lur is performed by 
UE Linking. 

Update of the S-MBMS Service Context when a PMM-CONNECTED UE, which has activated an 
S-MBMS Service, has left a cell. Update of the S-MBMS Service Context via lur is performed by UE 
Un-Linking. 
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5.1 .2 S-MBMS Session Start and S-MBMS Session Stop 

At S-MBMS Session Start and S-MBMS Session Stop the RNC receives a respective request from the CN. The 
S-MBMS Session Start request shall contain the S-MBMS Service Id, S-MBMS Bearer Service type and S-MBMS 
Session attributes (S-MBMS Service Area Information, QoS parameters, etc.). The S-MBMS Session Start request 
triggers the RNC to notify UEs, which have activated the S-MBMS Service of the S-MBMS Session Start. The 
S-MBMS Session Stop request may trigger the RNC to notify UEs, which have activated the S-MBMS Service of the 
S-MBMS Session Stop. 

The S-MBMS Session Start and Session Stop procedures provide the setup and release of the S-MBMS RAB in the 
following way: 

• The S-MBMS Session Start request shall contain all information necessary to setup an S-MBMS RAB. When 
the RNC receives an S-MBMS Session Start request, it typically executes S-MBMS lu data bearer set up and 
shall inform the sending CN node, of the outcome in the S-MBMS Session Start response message. 



• 



• 



The RNC may not execute the S-MBMS lu data bearer setup for a given lu interface in case of lu-flex. In 
those cases the CN node shall be informed accordingly. 

In case of lu-flex, the RNC might receive more than one S-MBMS Session Start request for an S-MBMS 
Service and shall not set up more than one S-MBMS lu bearer for a certain S-MBMS Service towards a pool 
area. 

When the RNC receives an S-MBMS Session Stop request it shall release the associated S-MBMS RAB 
resources. 

The S-MBMS Session Start and Session Stop procedures serve to establish and release the S-MBMS lu 
signalling connection. 



5.1.3 S-MBMS lu bearer 

For each S-MBMS service, data is transferred via an S-MBMS RAB between the SGSN and the UE. For each S-MBMS 
service, data is transferred via one S-MBMS lu bearer between SGSN and the RNC in the whole S-MBMS Service 
area. Signalling messages specific for an S-MBMS Service are transferred via one dedicated S-MBMS lu signalling 
connection between the RNC and the SGSN. 

1) One S-MBMS lu bearer is established per S-MBMS service at S-MBMS Session Start. 

2) Regarding lu-flex the RNC shall not set up more than one S-MBMS lu bearer. 

3) Because of the dedicated channels and lur mobility, there is a need to send S-MBMS data to an RNC which is 
not necessarily part of the S-MBMS Service area. 

4) The S-MBMS lu bearer on lu is established per S-MBMS service and not per UE individually. 

5) Each PMM-CONNECTED mode UE with an activated S-MBMS service has its UE context bind to the 
S-MBMS lu bearer. 

6) There could be several S-MBMS RBs linked to one S-MBMS lu bearer (i.e. one S-MBMS lu bearer on lu 
maybe mapped to multiple DTCH and/or or ptm traffic channels over the radio-interface). 

5.1.4 S-MBMS lub bearer 

The existing FACH transport channel mechanism over lub is to be used in case of ptm S-MBMS transmission. 
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5.1 .5 Mapping of S-MBMS lu bearer to ptm connections 

The service specific S-MBMS RAB on lu is mapped to ptm bearers in order to provide S-MBMS data via common 
channels. 

1) The S-MBMS control function in the CRNC establishes a ptm connection depending on the congestion 
scenario expected for a specific IMR cell (e.g. in hotspot areas where no bearer type switching is needed) 
and/or the S-MBMS service characteristics (e.g. session duration time) on per spot/IMR cell basis. 

2) The S-MBMS control function in the CRNC establishes an S-MBMS RB by sending service specific 
signalHng messages (e.g. S-MBMS RB Setup message) to all the UEs in the spot/IMR cell Hstening S-MBMS 
point- to -multipoint control channel (MCCH). UEs with activated service(s) may then execute the RB set-up. 

3) S-MBMS data is transferred on a S-MBMS point-to-multipoint traffic channel (MTCH) over ths spot/IMR cell 
coverage. 

4) The S-MBMS control function in the CRNC releases the S-MBMS RB (e.g. S-MBMS RB Release) when the 
data transfer has been finished or it has been interrupted by the CRNC. 

5) ptm transmission of S-MBMS data applies to all UE RRC states and modes. 



5.1.6 UE Linking 



UE Linking denotes the process where a UE, which has joined the S-MBMS service, is linked to an S-MBMS service 
context in the RNC and thus has an access to a reliable return link. 

S-MBMS UE Linking procedure in the SRNC is performed in following cases: 

1) When the UE, which has joined the S-MBMS service, is moved to PMM-CONNECTED and sets up a PS 
RAB. This may happen at any point in time during the whole S-MBMS service availability (i.e. before, during 
and between S-MBMS sessions). 

2) When the UE joins the S-MBMS service and is in PMM-CONNECTED due to an existing PS RAB. This may 
happen at any point in time during the whole S-MBMS service availability (i.e. before, during and between 
S-MBMS sessions). 

3) When the UE is moved to PMM-CONNECTED only for S-MBMS purpose, e.g. to respond to 
counting/recounting indication or respond to ptp bearer indication from RNC. This may happen at any point in 
time during S-MBMS sessions. 

Keeping UEs in PMM-CONNECTED only for S-MBMS between sessions is implementation specific. The UE Linking 
in the SRNC is performed via UE dedicated lu procedures. An entry for the UE is added to the S-MBMS service 
context in the SRNC. If the S-MBMS service context doesn't exist yet it needs to be created. 

In cases where a UE is present in a spot/IMR cell under the control of a drift RNC, or a UE in URA_PCH state is 
present within a URA containing one or more spot/IMR cells that are controlled by one or more drift RNCs, the UE 
Linking is performed via lur in the following way. 

1) When the UE, which has activated one or several S-MBMS services, is in CELL_DCH or CELL_FACH state 
and starts to consume radio resources from one or several spot/IMR cells controlled by the DRNC, S-MBMS 
UE Linking in the DRNC is performed via UE dedicated lur procedures. 

2) If the UE is in CELL_DCH and CELL_FACH state and there is no dedicated RNL signalling activity ongoing 
for this UE and UE Linking is performed in the SRNC for an S-MBMS Service, S-MBMS UE Linking in the 
DRNC is performed via the S-MBMS Attach procedure. 

3) If the UE is in CELL_PCH and moves to a spot/IMR cell controlled by the DRNC, the S-MBMS UE Linking 
in the DRNC is performed. The cell the UE moved to is indicated to the DRNC. After that the S-MBMS 
Service context in the DRNC needs to be updated at every intra-DRNC spot/IMR cell change. 
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4) If the UE is in URA_PCH, having activated one or more S-MBMS services, is the first UE for the particular 
S-MBMS service to move to a URA which contains one or more spots/IMR cells that are controlled by one or 
more DRNCs, the UE is linked to the S-MBMS Service context in each appUcable DRNC. The URA the UE 
moved to will be indicated. The S-MBMS Service context in each applicable DRNC needs to be updated at 
every intra-DRNC URA change. 

5) As long as the SRNC serves UEs in URA_PCH in URAs containing spot/IMR cells controlled by one or more 
DRNCs, the SRNC shall keep the other RNCs informed about every URA in which UEs having activated 
certain S-MBMS services have to be notified. This is done when the first UE enters the URA, by indicating to 
the other RNCs a list of URAs and the corresponding S-MBMS Services. 

6) If the UE is in CELL_PCH or URA_PCH and there is no mobility related signalling activity ongoing for this 
UE and UE Linking is performed in the SRNC for an S-MBMS Service, S-MBMS UE Linking in the DRNC 
is performed via the S-MBMS Attach procedure. 

7) If the UE is in CELL_PCH and leaves a spot/IMR cell controlled by the DRNC the UE is unlinked from the 
S-MBMS Service context in the DRNC via the S-MBMS Detach procedure. 

8) If the UE is in URA_PCH and, for the particular S-MBMS service, is the last UE to leave a URA which 
contains one or more cells controlled by one or more DRNCs the UE is unlinked from the S-MBMS Service 
context in each applicable DRNC via the S-MBMS Detach procedure. 

9) If the UE is in RRC connected mode and UE Linking is performed in the SRNC for an S-MBMS Service and a 
session of this S-MBMS Service is ongoing UE Linking in the DRNC needs to be performed immediately. 

At S-MBMS UE Linking in the DRNC the S-MBMS service context in the DRNC needs to be updated. If an S-MBMS 
service context does not exist yet then it shall be created. 

5.1.7 RNC Registration 

This clause applies to multicast and to UE which has an access to a reliable return link. 

RNC Registration for a certain S-MBMS Service denotes the process where the CN becomes aware of an RNC hosting 
UEs, which have activated that S-MBMS Service. 

Due to UE mobility, a RNC with no S-MBMS Service Context, can be informed that a PMM-CONNECTED UE, which 
has entered the spot/IMR cell, has activated an S-MBMS Service by means of the S-MBMS UE Linking procedure via 
the lur interface. Then the RNC informs the CN that it would like to receive S-MBMS Session Start request messages 
when applicable for the concerned S-MBMS Service by sending S-MBMS Registration request message. 

It results in the set-up of a corresponding S-MBMS distribution tree, but it does not result in the establishment of lu user 
plane, which will be established by the S-MBMS Session Start procedure. 

1) Implicit Registration: 

RNC Registration for Serving RNCs is performed implicitly, i.e. due to UE linking and S-MBMS 
Multicast Service Activation. No explicit registration procedure needs to be performed. 

2) Exphcit Registration: 

RNC Registration for Drift RNCs is performed explicitly if an RNC becomes a Drift RNC for a UE, 
which has activated an S-MBMS service and has no S-MBMS Service Context for that S-MBMS 
Service. 

RNC Registration for Drift RNCs is performed explicitly if an RNC is no longer the SRNC of any 
connected UE which has activated an S-MBMS service, but hosts at least a UE which consumes radio 
resources of the RNC via lur. This shall happen only before sessions or between sessions. 

The DRNC will perform a registration towards its default CN node only. 
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5.1.8 RNC De-Registration 

This clause applies to multicast and to UE which has an access to a reliable return link. 

RNC De-Registration for a certain S-MBMS Service denotes the process where the CN becomes aware that an RNC 
registered at a CN node does not host any more PMM-CONNECTED UEs which have activated that S-MBMS Service. 

1) ImpHcit RNC De-Registration: 

RNC De-Registration for Serving RNCs is performed implicitly, i.e due to UE Unlinking and S-MBMS 
Multicast Service Deactivation. No explicit de-registration procedure needs to be performed. 

2) ExpUcit RNC De-Registration: 

RNC De-Registration for Drift RNCs is performed explicitly if a RNC is not acting as a Serving RNC 
and has ceased to act as a Drift RNC for UEs which have activated an S-MBMS service, it will perform a 
de-registration towards the CN node it was registered to. 

The timing of RNC De-Registration is implementation specific. 



5.1.9 CN De-Registration 



CN De-Registration denotes the process where the CN informs the RNC that a certain S-MBMS service is no longer 
available. CN De-Registration should result in releasing of all associated S-MBMS Service Contexts and resources. 

The CN De-Registration procedure serves to release the S-MBMS lu signaling connection. 

5.2 S-MBMS Uu Principles 
5.2.1 S-MBMS Service States in UE 

The S-MBMS bearer service has following service states in the UE: 

1) Not active: UE has not joined any S-MBMS multicast service or not activated the broadcast mode of the 
S-MBMS. 

2) Not active: UE has joined at least one S-MBMS multicast service and/or activated the broadcast mode of the 
S-MBMS, but S-MBMS SYSTEM INFORMATION is not broadcast on BCCH. 

3) Active: UE has joined at least one S-MBMS multicast service and/or activated the broadcast mode of the 
S-MBMS, but any of the services that UE has joined (interested in broadcast mode) is not being transmitted. 
UE monitors MICH to find modifications in the MCCH as defined in clause 5.1.6. 

4) Active: at least one S-MBMS multicast service which the UE has joined (interested in broadcast mode) is 
transmitted on ptm: 

UE is receiving S-MBMS transmission on MTCH; 

UE is using DRX based on scheduling information informing that coming MTCH transmission is not in 
the interest of the UE. 

When S-MBMS transmission is started in spot/IMR cell the UE moves from state 3 to either state 4, and after S-MBMS 
transmission ends in the spot/IMR cell, the UE moves from state 4 to state 3. 



£75/ 



15 ETSI TS 102 442-3 VI. 1.1 (2006-11) 

5.2.2 One PDCP and RLC entity shared among multiple spots within one 
RNS 

For each S-MBMS service, a group of multiple spots/IMR cells belonging to one RNS shares one PDCP entity and 
RLC entity over ptm transmission. The group of multiple spots/IMR cells is called "S-MBMS Cell Group". 

1) There are one or more S-MBMS Cell Groups per S-MBMS service per RNS. The S-MBMS Cell Groups are 
managed by the CRNC. 

2) There are one or more cells pertaining to the same RNS for one S-MBMS Cell Group. 

3) For each S-MBMS service, the S-MBMS Cell Group Identifier (S-MBMS CG-Id) is used to uniquely identify 
a group of multiple spots/IMR cells sharing the same PDCP entity and RLC entity within an RNS. 

4) For each S-MBMS service, the S-MBMS CG-Id together with the identifier of the controlling RNC 
(CRNC-Id) constitutes the S-MBMS USRAN Cell Group Identifier (S-MBMS UCG-Id). 

5) Each spot/IMR cell sends the S-MBMS UCG-Id to UEs for each S-MBMS service. The S-MBMS UCG-Id is 
used to uniquely identify an S-MBMS Cell Group in the USRAN and UE. 

5.2.3 MCCH information scheduling 

The MCCH information will be transmitted based on a fixed schedule. This schedule will identify the TTI containing 
the beginning of the MCCH information. The transmission of this information may take a variable number of TTIs and 
USRAN should transmit MCCH information on consecutive TTIs. The UE will keep receiving the S-CCPCH until: 

• it receives all of the MCCH information; or 

• it receives a TTI that does not include any MCCH data; or 

• the information contents indicate that further reception is not required (e.g. no modification to the desired 
service information). 

Based on this behaviour, the USRAN may repeat the MCCH information following a scheduled transmission in order to 
improve reliability. The MCCH schedule will be common for all services. 

The entire MCCH information will be transmitted periodically based on a "repetition period". The "modification 
period" will be defined as an integer multiple of the repetition period. The MBMS ACCESS INFORMATION may be 
transmitted periodically based on an "access info period". This period will be an integer divider of the "repetition 
period". 

MCCH information is split into critical and non-critical information. The critical information is made up of the MBMS 
NEIGHBOURING CELL INFORMATION, MBMS SERVICE INFORMATION and MBMS RADIO BEARER 
INFORMATION. The non-critical information corresponds to the MBMS ACCESS INFORMATION. Changes to 
critical information will only be applied at the first MCCH transmission of a modification period and in the beginning 
of each modification period USRAN transmits the MBMS CHANGE INFORMATION including S-MBMS services ids 
whose MCCH information is modified at that modification period. MBMS CHANGE INFORMATION is repeated at 
least once in each repetition period of that modification period. Changes to non-critical information could take place at 
any time. 

Figure 5.1 illustrates the schedule with which the MBMS SERVICE INFORMATION and RADIO BEARER 
INFORMATION would be transmitted. Different colours indicate potentially different MCCH content. 
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Figure 5.1 : MCCH Information Schedule 

5.2.4 S-MBMS Notification 

The S-MBMS notification mechanism is used to inform UEs of an upcoming change in critical MCCH information. 
Notifications are based on service groups. The mapping between service IDs and service groups will be based on a 
hashing mechanism. 

The S-MBMS notification indicators is sent on an S-MBMS specific PICH, called the MICH. A single MICH frame is 
able to carry indications for every service-group. 

Critical MCCH information can only be changed at the beginning of a modification period as described in clause 5.2.3. 
The S-MBMS notification indicator corresponding to the service group of every affected service shall be set 
continuously during the entire modification period preceding the first change in MCCH information related to a given 
service. Subsequent changes in the MCCH information in the next modification period related to the same service can 
be signalled on the MCCH. 

UEs which are not receiving any S-MBMS service on MTCH are free to read the S-MBMS notification at any time; 
however the modification interval shall be long enough so that UEs are able to reUably detect it even if they only 
receive the MICH during their regular Release 9 paging occasions. 

Upon detecting the S-MBMS notification indication for a service group, UEs interested in a service corresponding to 
this group shall start reading the MCCH at the beginning of the next modification period. The UE shall read at least 
MBMS CHANGE INFORMATION. 

Figure 5.2 illustrates the timing relation between the setting of the MICH and the first MCCH critical information 
change. The green colour for the MICH indicates when the NI is set for the service. For the MCCH, different colours 
indicate MCCH content related to the notification of different services. 

UEs, which are receiving S-MBMS service(s) on MTCH in idle mode or URA_PCH, CELL_PCH, or CELL_FACH 
state shall read the MCCH at the beginning of the each modification period to receive the MBMS CHANGE 
INFORMATION, which will indicate S-MBMS service Ids whose MCCH information is modified at that modification 
period. If S-MBMS service Id, which UE has activated, is indicated in S-MBMS CHANGE INFORMATION the UE 
shall read the rest of the MCCH information. 
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Figure 5.2: Illustration of MICH timing relative to Modification period 
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5.2.5 S-MBMS Counting 

S-MBMS Counting is used to determine the optimum transmission mechanism for a given service. 

1) The need for counting is indicated in the notification, and achieved by requesting UEs, belonging to the same 
S-MBMS service group, to report. 



2) 
3) 

4) 



The exact number of UEs that need to be brought to RRC (satellite Hub) is an RRM issue. 

Since it is desirable in a specific spot/IMR cell, to avoid bringing a large number of UEs for counting purposes 
to transmit SMS at the same time (RACH load, etc.), RRM may control the load due RACH access attempt, by 
setting an access "probability factor". 



For a given S-MBMS service, the counting indication in the notification may be switched on and off, on 
per-spot/lMR cell basis. 



5) The RNC may use notification to indicate counting during an ongoing S-MBMS session (term used is 
re-counting). 

The S-MBMS counting function includes a mechanism by which the USRAN can prompt users interested in a given 
service to transmit SMS. This procedure is only applicable for UEs in idle mode and relies on the MBMS ACCESS 
INFORMATION transmitted on the MCCH. The probability factor indicates the probability with which UEs need to 
attempt SMS transmission. 

In order to trigger counting for a given service, the USRAN may use the regular S-MBMS notification mechanism 
outlined in clause 5.2.4 to force UEs interested in the service to read the MCCH information. 

Once a UE detects that the counting procedure is on-going for the specific service it wants to receive, it will attempt to 
set up an RRC connection based on the probability factor included in the MCCH. 

Also, the UE will keep receiving the MBMS ACCESS INFORMATION at every access info period until UE transmit 
SMS or counting is no longer required. Whenever it receives new MBMS ACCESS INFORMATION the UE will 
update its probability factor with the new value. 

Figure 5.3 illustrates this mechanism. The green colour for the MICH indicates when the NI is set for the service. The 
green colour for the MBMS ACCESS INFORMATION indicates that the counting procedure is on-going and that UEs 
need to transmit SMS based on the included Probability Factor (PF). For the critical MCCH info, different colours 
indicate potentially different content. 
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Figure 5.3: Illustration of Access Info period during S-MBMS counting 

Counting for on-going services (re-counting) relies on the same scheduling of the MCCH information. 
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5.2.6 S-MBMS Radio Bearer Release in tine UE 

The UE releases the S-MBMS Radio Bearer by using one of the following mechanisms: 

• ExpHcit S-MBMS RB Release. 

• ImpHcit S-MBMS RB Release. 

The ExpHcit S-MBMS RB Release mechanism allows USRAN to expHcitly indicate to S-MBMS UEs that an S-MBMS 
Radio Bearer should be released. For ptm transmissions the Explicit S-MBMS RB Release indication is contained 
within the MBMS SERVICE INFORMATION signalling flow. For ptp transmission the release of S-MBMS radio 
bearers is completed in the same way as for a non- S-MBMS radio bearer. If the Explicit S-MBMS RB Release 
indication is received, the UE releases the S-MBMS RB. 

The Implicit S-MBMS RB Release mechanism applies only to ptm transmission and enables a UE to release the 
S-MBMS Radio Bearer without receiving the Explicit MBMS RB Release. The UE identifies Implicit MBMS RB 
release if it detects that the RB is not present in the MBMS SERVICE INFORMATION signalling flow. 



5.2.7 S-MBMS Session Repetition 



In the case that the BM-SC repeats S-MBMS sessions (send multiple time identical content), the S-MBMS service Id 
and S-MBMS session Id is used to identify specific S-MBMS service and session. The validity of the session Id is 
handled on the S-MBMS appHcation layer between the BM-SC and the UE. If USRAN receives the S-MBMS session 
ID in session start, the USRAN should: 

1) include S-MBMS session Id in critical and non critical information send on MCCH; 

NOTE: The non-critical information may contain index referring to critical information, avoiding repetition of 
S-MBMS service and session Id in non-critical information. 

If the UE has already received correctly the data of the S-MBMS session, which is being indicated on MCCH, the UE 

may: 

1) ignore FLC by not applying the Layer Convergence Information; 

2) ignore counting procedure in Idle, URA_PCH, CELL_PCH, and CELL_FACH state; 

3) ignore ptm S-MBMS RB setup signalled on MCCH; 

4) ignore ptp S-MBMS RB indication signalled on MCCH; 

5) reject the ptp RB setup for S-MBMS service, signalled on DCCH. 

In the case that USRAN receives reject from the UE to the ptp RB setup for S-MBMS service on DCCH, the USRAN 
should not try to re-establish ptp RB setup for that S-MBMS service and session. 

In the case that the UE has accepted the ptp RB for repeated S-MBMS session the UE shall receive the complete 
session. 

5.2.8 S-MBMS Service Prioritization 

The CN may assign the Allocation and Retention Priority for the S-MBMS bearer service. The Allocation and 
Retention Priority allows for prioritization between S-MBMS bearer services and between S-MBMS bearer services 
and non S-MBMS bearer services in the USRAN. 

The UE may assign internally different priorities for different S-MBMS services to prioritize S-MBMS and non 
S-MBMS service reception. In case that UE has no capability to receive simultaneously, the dedicated non S-MBMS 
service and the S-MBMS service and the S-MBMS service has priority over the non S-MBMS service the UE may 
follow procedure defined in [ 1 ] . 
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5.3 



Protocol structure 



5.3.1 S-MBMS User Plane Protocol Stack Architecture 
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Figure 5.4: Protocol stacic for lUITCH 



If configured by CRNC the PDCP sub-layer performs header compression/decompression for the S-MBMS traffic. 
PDCP sub-layer may operate with RFC 3095 (see Bibliography) U-mode header compression protocol. 

In the USRAN, there is: 

• one PDCP entity per spot for each S-MBMS service; 

• one RLC entity for each S-MBMS service in each spot; 

• one RLC entity for each S-MBMS service in each IMR cell in case of utilization of selective combining; 

• one MAC entity for each spot; 

• one MAC entity for each IMR cell in case of utilization of selective combining. 

In the UE, there is one PDCP and RLC entity for each S-MBMS service, and one MAC entity per received spot/cell 
when UE is performing the selective combining between the spot and IMR cells. 

5.3.2 S-MBMS Control Plane Protocol Stack Architecture 
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Figure 5.5: Protocol stack for MCCH and MSCH 
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5.4 



MAC architecture 



5.4.1 USRAN MAC Architecture to support S-IVIBIVIS 

The MAC architecture consists of 3 logical entities as illustrated in figure 5.6: 

• MAC-b for broadcast of system information (BCCH); 

• MAC-c for scheduling of ptp signalling, activated if a return link is reliable; 

• MAC-m for scheduling of S-MBMS transport channels. 



MAC, control 




BCH FACH FACH FACH RACH 

Figure 5.6: USRAN MAC architecture 



5.4.2 IVIAC-m architecture: USRAN side 
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Figure 5.7: USRAN side lUIAC-m architecture 

MAC-m is located in the satellite Hub (controlling RNC). The following functionalities are covered: 

• Scheduling / Buffering / Priority Handling: this function manages common transport resources between 
S-MBMS and non-S-MBMS data flow(s) according to their priority. 

• TCTF MUX: this function handles insertion of the TCTF field in the MAC header and also the respective 
mapping between logical channels (i.e. MTCH and MCCH) and transport channels. The TCTF field indicates 
which type of logical channel (i.e. MTCH and MCCH) is used. 
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• Addition of S-MBMS-ID: for ptm type of logical channels, the S-MBMS-ID field in the MAC header is used 
to distinguish between S-MBMS services. 

• TFC selection: transport format combination selection is done for a common transport channel (FACH) 
mapped to MTCH, MCCH and MSCH. 



5.4.3 MAC-m architecture: UE side 
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Figure 5.8: UE side lUIAC-m architecture 

The following functionalities are covered: 

• TCTF DEMUX: this function handles detection and deletion of the TCTF field in the MAC header, and also 
the respective mapping between logical channels (i.e. MTCH and MCCH) and transport channels. The TCTF 
field indicates which type of logical channel (i.e. MTCH and MCCH) is used. 

• Reading of S-MBMS-ID: the S-MBMS-ID identifies data to a specific S-MBMS service. 

There is one MAC-m entity in the UE or in case of selective combining one MAC-m entity for each selectively 
combined spot/IMR cell in the UE. 



6.1 



Void. 



S-MBMS Channel Structure 



Point-to-Point Transmission 



6.2 Point-to-multipoint Transmission 

Point-to-multipoint transmission is used to transfer S-MBMS specific control/user plane information between the 
network and several UEs in RRC Connected or Idle Mode. It is used for broadcast or multicast mode of S-MBMS. 
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6.2.1 Logical Channels 

6.2.1 .1 S-MBMS point-to-multipoint Control Channel (MCCH) 

MCCH is used for a ptm downlink transmission of control plane information between satellite Hub and UEs in RRC 
Connected or Idle Mode. The control plane information on MCCH is S-MBMS specific and is sent to UEs in a spot 
(with an activated (joined) S-MBMS service). MCCH can be sent in standalone S-CCPCH, or in same S-CCPCH with 
MTCH. 

The MCCH is always mapped to one specific FACH in the S-CCPCH as indicated on the BCCH. In case of soft 
combining, the MCCH is mapped to separate S-CCPCH (CCTrCH in TDD) than MTCH. 

Reception of paging has priority over reception of MCCH for Idle mode and URA/CELL_PCH UEs. 

6.2.1 .2 S-MBMS point-to-multipoint Traffic Channel (MTCH) 

This logical channel is used for a ptm downlink transmission of user plane information between satellite Hub and UEs 
in RRC Connected or Idle Mode. The user plane information on MTCH is S-MBMS Service specific and is sent to UEs 
in a spot with an activated S-MBMS service. 

6.2.1 .3 S-MBMS point-to-multipoint Scheduling Channel (MSCH) 

This logical channel is used for a ptm downlink transmission of S-MBMS service transmission schedule between 
network and UEs in RRC Connected or Idle Mode. The control plane information on MSCH is S-MBMS service and 
S-CCPCH specific and is sent to UEs in a spot/IMR cell receiving MTCH. One MSCH sent in each S-CCPCH carrying 
the MTCH. 

The MSCH is always mapped to one specific FACH in the S-CCPCH as indicated on the MCCH. Due to different error 
requirements the MSCH is mapped to separate FACH than MTCH. 

6.2.2 Transport Channel 

EACH is used as a transport channel for MTCH, MSCH and MCCH. 

6.2.3 Physical Channel 

S-CCPCH is used as a physical channel for FACH carrying MTCH or MSCH or MCCH. 

6.2.4 Mapping between channels 

The following connections between logical channels and transport channels exist: 

• MCCH is mapped to FACH; 

• MTCH is mapped to FACH; 

• MSCH can be mapped to FACH. 

The mappings as seen from the UE and USRAN sides are shown in figure 6.1 and figure 6.2 respectively. 
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Figure 6.1 : Mapping of logical channels onto transport channels; UE side 
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Figure 6.2: IVIapping of logical channels onto transport channels; USRAN side 



6.2.5 Data Flows through Layer 2 



6.2.5.1 



Data flow for MCCH mapped to FACH 



For MCCH, RLC is configured in UM mode, with required enhancements to support out of sequence SDU delivery. 
A MAC header is used for logical channel type identification. 

6.2.5.2 Data flow for MTCH mapped to FACH 

For MTCH, RLC is configured in UM mode, with required enhancements to support selective combining when IMRs 
are deployed and configured with a scrambling code different that the satellite one. 

Quick repeat may be used (in UM mode). A MAC header is used for logical channel type identification and S-MBMS 
service identification. 



6.2.5.3 



Data flow for MSCH mapped to FACH 



For MSCH, RLC is configured in UM mode, with required enhancements to support out of sequence SDU delivery. 
A MAC header is used for logical channel type identification. 



6.3 



S-MBMS Notification Indicator Channel 



S-MBMS notification is broadcast through S-MBMS Notification Indicator Channel (MICH). 
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7 S-MBMS Reception and UE Capability 

7.1 Selective and Soft Combining for S-MBMS PTM 
transmission 

The selective combining for S-MBMS ptm transmission is supported by RLC PDU numbering. Therefore, the selective 
combining in the UE is possible from spots/IMR cells providing similar S-MBMS Radio Bearer bit rate, provided that 
the de-synchronization between S-MBMS ptm transmission streams does not exceed the RLC re-ordering capability of 
the UE. Thus, there exist one RLC entity in the UE side. 

To support selective combining it is decided to: 

• Introduce re-ordering as a configurable feature of RLC-UM, within the RLC specification. 

• Use the same mechanism as what is specified for MAC-hs (single Tl timer). 

For selective combining there exist one RLC entity per S-MBMS service utilizing ptm transmission in the spot/IMR cell 
group of the satellite Hub (CRNC). All spot/IMR cells in the group are under the same satellite Hub (CRNC), i.e. lur 
support is not considered. 

The UE capability requirements to support selective and soft combining are defined in clause 7.2. In case 
de-synchronization occurs between S-MBMS transmissions in neighbouring spot/IMR cells belonging to an S-MBMS 
spot/IMR cell group the satellite Hub (CRNC) may perform re-synchronization actions enabling UEs to perform the 
selective combining between these spots/IMR cells. 

Soft combining can be used when spots/IMR cells are synchronized inside UE's soft combining reception window, and 
the content of the soft combined S-CCPCH is identical during soft combining moments. 

When selective combining or soft is available between spots/IMR cells the UTRAN should send MBMS 
NEIGHBOURING CELL INFORMATION containing the MTCH configuration of the neighbouring spots/IMR cells, 
available for selective or soft combining. When soft combining is applied the MBMS NEIGHBOURING CELL 
INFORMATION contains the LI -combining schedule, which indicates the time moments when the UE shall soft 
combine the S-CCPCH transmitted in different spots/IMR cells. With MBMS NEIGHBOURING CELL 
INFORMATION the UE is able to receive MTCH transmission from neighbouring spot/IMR cell without reception of 
the MCCH of that spot/IMR cell. 

The UE determines the neighbouring spot/IMR cell suitable for selective or soft combining based on threshold 
(e.g. measured CPICH Ec/No) and the presence of MBMS NEIGHBOURING CELL INFORMATION of that 
neighbour spot/IMR cell. 

The possibility of performing selective or soft combining should be signalled to the UE. 
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7.2 UE Capability 



The minimum UE capability for S-MBMS capable UE, is one primary CCPCH plus all the configurations below. 
The UE is not required to support these configurations simultaneously. 

1 ) One PICH and one MICH. 

2) One S -CCPCH and one MICH. 

3) One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and two S-CCPCH with 
80ms TTI for MTCH reception. 

4) One S-CCPCH (dedicated EACH and possibly the EACH, which may carry MCCH) and three S-CCPCH with 
40 ms TTI for MTCH reception. 

5) One PICH and two S-CCPCH with 80 ms TTI for MTCH reception. 

6) One PICH and three S-CCPCH with 40 ms TTI for MTCH reception. 
UE shall support selective and soft combining. 

296 chips reception window for soft combining. 

7.3 S-IVIBIVIS Reception 

The BCCH contains information regarding the MCCH, while the latter contains information on the MTCH. 

7.3.1 S-IVIBIVIS Reception in RRC Idle Mode 

In idle mode, the UE shall: 

• if the UE supports S-MBMS; and 

• if the UE has activated an S-MBMS service and there is an ongoing session for this service in the spot/IMR 
cell where the UE is situated, i.e. MTCH and MCCH are available: 

act on RRC messages received on MCCH; and 

if the S-MBMS service requires the establishment of an RRC Connection/sending of an SMS 
(see UE counting); 

■ inform upper layers that the S-MBMS Service requires the establishment of an RRC 
Connection/sending of an SMS; 

if the S-MBMS service does not require the establishment of an RRC Connection/sending of an SMS: 

■ listen to the common transport channel on which the MTCH is mapped. 

if the UE determines that a neighbouring spot/IMR cell is suitable for selective or soft combining and the 
UE has valid S-MBMS NEIGHBOURING CELL INEORMATION of that spot/IMR cell: 

■ performs selective or soft combining of MTCH between the selected spot/IMR cell and the 
neighbouring spot/IMR cell. 
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7.3.2 S-MBMS Reception in RRC Connected Mode: URA_PCH state 

In URA_PCH, the UE shall: 

• if the UE supports S-MBMS; and 

• if the UE has activated an S-MBMS service and there is an ongoing session for this service in the URA where 
the UE is situated, i.e. MTCH and MCCH are available: 

act on RRC messages received on MCCH; 

if on the MCCH is indicated that the S-MBMS service in the spot/IMR cell requires a cell update: 

■ initiate a cell update procedure. 

for each S-MBMS service that the UE has activated and where transmission on a MTCH is indicated in 
the MCCH, listen to the common transport channel on which the MTCH is mapped; 

if the UE determines that a neighbouring spot/IMR cell is suitable for selective or soft combining the UE 
has vaUd S-MBMS NEIGHBOURING CELL INFORMATION of that spot/IMR cell: 

■ performs selective or soft combining of MTCH between the selected spot/IMR cell and the 
neighbouring spot/IMR cell. 

7.3.3 S-MBMS Reception in RRC Connected Mode: CELL_PCH state 

In CELL_PCH, the UE shall: 

• if the UE supports S-MBMS; and 

• if the UE has activated an S-MBMS service and there is an ongoing session for this service in the spot/IMR 
cell where the UE is situated, i.e. MTCH and MCCH are available: 

act on RRC messages received on MCCH; 

listen to the common transport channel on which the MTCH is mapped; 

if the UE determines that a neighbouring spot/IMR cell is suitable for selective or soft combining the UE 
has valid MBMS NEIGHBOURING CELL INFORMATION of that spot/IMR cell. 

• performs selective or soft combining of MTCH between the selected spot/IMR cell and the neighbouring 
spot/IMR cell. 

7.3.4 S-MBMS Reception in RRC Connected Mode: CELL_FACH state 

In CELL_FACH, the UE shall: 

• if the UE supports S-MBMS; and 

• if the UE has activated an S-MBMS service and there is an ongoing session for this service in the spot/IMR 
cell where the UE is situated, i.e. MTCH and MCCH are available: 

act on RRC messages received on MCCH; 

listen to the common transport channel on which the MTCH is mapped; 

if the UE determines that a neighbouring spot/IMR cell is suitable for selective or soft combining the UE 
has valid MBMS NEIGHBOURING CELL INFORMATION of that spot/IMR cell: 

■ performs selective or soft combining of MTCH between the selected spot/IMR cell and the 
neighbouring spot/IMR cell. 
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7.3.5 S-MBMS Reception in RRC Connected Mode: CELL_DCH state 

In CELL_DCH, the UE shall: 

• if the UE supports S-MBMS; and 

• if the UE has activated an S-MBMS service and there is an ongoing session for this service in the spot/IMR 
cell where the UE is situated, i.e. MTCH and MCCH are available; and 

• if the UE has the capabilities: 

act on RRC messages received on MCCH; 

listen to the common transport channel on which the MTCH is mapped: 

■ if the UE determines that a neighbouring spot/IMR cell is suitable for selective or soft combining 
the UE has valid MBMS NEIGHBOURING CELL INFORMATION of that spot/IMR cell and UE 
has capability. 

performs selective or soft combining of MTCH between the selected spot/IMR cell and the neighbouring 
spot/IMR cell. 



8 USRAN Signalling Flows for S-MBMS 

8.1 S-MBMS Higln Level Signalling Scenarios 
8.1.1 Session start 

Upon receiving a session start indication from CN, USRAN initiates the session start sequence to allocate radio 
resources to UEs for receiving the S-MBMS content. As part of this sequence, USRAN may apply the counting 
procedure (counting the number of idle mode UEs). 



UE 



USRAN 



1 . Notification for session start 



2. IVIBIVIS RB (IVITCH) establisliment 



3. S-IVIBIVIS data transfer 



Figure 8.1 : Session start 

In general, the session start sequence involves the following steps: 

• In case USRAN applies counting the following steps are performed: 

USRAN sets the correct S-MBMS Notification Indicator (NI) and sends the MBMS CHANGE 
INFORMATION and the MBMS ACCESS INFORMATION including service ID, and access 
probabihty on MCCH. 
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Upon DRX wakeup, UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH 
evaluate the S-MBMS NI and if set, read the MBMS CHANGE INFORMATION from MCCH. If 
service Id of activated S-MBMS service is indicated in MBMS CHANGE INFORMATION UEs 
continue reading the rest of MCCH information. Upon receiving the MBMS ACCESS INFORMATION 
including access probability, UEs in idle mode or URA_PCH state for which the probability check 
passes, initiate SMS transfer. UEs in CELL_PCH or CELL_FACH state ignore the MBMS ACCESS 
INFORMATION. USRAN counts the UEs interested in the S-MBMS service using UE linking from CN. 

RRC Connected mode. In the case that no UE is counted as present in the spot/IMR cell then USRAN 
may decide not to provide any RB for the service in the spot/IMR cell. 

• USRAN activates the ptm RB establishment procedure: 

USRAN configures MTCH and updates MCCH (MBMS SERVICE INFORMATION and MBMS 
RADIO BEARER INFORMATION) by including the service ID and ptm RB information for the 
concerned S-MBMS service. 

USRAN sends the S-MBMS dedicated notification message including the service ID and cause = Session 
Start on DCCH to inform UEs in CELL_DCH that are not receiving an S-MBMS service provided using 
ptm transfer mode. 

Upon DRX wakeup, UEs not receiving MTCH evaluate the S-MBMS NI and if set, read MCCH at 
beginning of modification period to acquire MBMS CHANGE INFORMATION. UEs in idle mode as 
well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an S-MBMS service read the 
MBMS CHANGE INFORMATION directly. If service Id of activated S-MBMS service is indicated in 
MBMS CHANGE INFORMATION UEs continue reading the rest of MCCH information to acquire the 
MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION. 

UEs that are incapable of receiving the MTCH for the session that is started in parallel to the existing 
activity notify the user. This enables the user to choose between the ongoing activity and the new 
S-MBMS service. 

Upon receiving the MBMS SERVICE INFORMATION and the MBMS RB INFORMATION including 
the ptm RB information for the concerned S-MBMS service, the UE starts receiving the ptm radio 
bearers. 

8.1 .2 Joining (during a session) 

In case the user wants to join an S-MBMS service (before or during a session), the UE initiates NAS procedures 
(e.g. S-MBMS service activation). 

If no session is ongoing upon completion of the joining procedure, the joining procedure is transparent to the AS. 

In case a session is ongoing upon completion of the joining procedure, the UE may initiate reception of the ptm radio 
bearers. 
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UE 



USRAN 



1. Joining (NAS) 



2. Initiate reception of PTIVI RBs 



3. S-IVIBIVIS data transfer, PTIVI 



Figure 8.2: Joining with continuation of PTIVI 

In general, the joining sequence involves the following steps: 

• UEs initiate the joining procedure (NAS); 

• Then: 

USRAN sends the S-MBMS dedicated notification message on DCCH including the service ID and 
cause = session ongoing to inform UEs in CELL_DCH. 

Upon receiving S-MBMS dedicated notification with cause= session ongoing, UEs in CELL_DCH that 
are incapable of receiving the MCCH and the corresponding MTCH in parallel to the existing activity 
notify the upper layer. This enables the user to choose between the ongoing activity and the new 
S-MBMS service. If the user chooses to receive the new S-MBMS service or if the UE in Cell_DCH is 
capable of receiving MCCH and MTCH in parallel to the existing activity, the UE shall read MCCH to 
acquire the MBMS SERVICE INFORMATION and MBMS RADIO BEARER INFORMATION from 
MCCH. 

Upon acquiring the MBMS SERVICE INFORMATION and the MBMS RADIO BEARER 
INFORMATION including the ptm RB information for the concerned S-MBMS service, the UE starts 
receiving the ptm radio bearers. 



8.1.3 

Void. 



Recounting 



8.1.4 Session stop 



USRAN may apply the session stop procedure to inform UEs that the end of MTCH transmission concerns the end of a 
session rather than just an idle period. The purpose of the procedure is to reduce the UE power consumption. 
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UE 



USRAN 



1 . Termination of S-MBIVIS data transfer, PTIVI 



2. Notification for session stop 



Figure 8.3: Session stop 

The session stop sequence involves the following steps: 

• USRAN sends the MBMS CHANGE INFORMATION and the MBMS RADIO BEARER INFORMATION 
including service ID and radio bearer release indicator. USRAN updates MCCH (MBMS SERVICE 
INFORMATION) to inform UEs joining or entering the spot/IMR cell in a later point of time. 

• UEs in idle mode as well as UEs in CELL_PCH, URA_PCH and CELL _FACH receiving an S-MBMS 
service read the MBMS CHANGE INFORMATION at the beginning of the each modification period. If 
service Id of activated S-MBMS service is indicated in MBMS CHANGE INFORMATION UEs continue 
reading the rest of MCCH information. 

• Upon receiving this information the UE stops receiving the MTCH. 



8.2 S-MBMS RNC Signalling Flows 
8.2.1 S-MBMS Session Start procedure 



RNC 




ON 




, [F 


RANAP] MBMS SESSION STA 


RT 






REQUEST 
[RANAP] MBIVIS SESSION START 








RESPONSE 







Figure 8.4: S-IUIBIVIS Session Start procedure. Successful operation 

The MBMS Session Start procedure is initiated by the CN when an S-MBMS Session is started. The MBMS SESSION 
START REQUEST is sent to each RNC (satellite Hub) that is connected to the CN. 

The MBMS SESSION START REQUEST contains the S-MBMS Service Id, S-MBMS Bearer Service Type and the 
S-MBMS Session Attributes (S-MBMS Service Area Information, QoS parameters, etc.) It may also include a list of 
RAs which lists each RA that contains at least one PMM-IDLE UE that has activated the service. 

S-MBMS Session Start procedure also provides the S-MBMS lu Data Bearer Establishment functionality. If the RNC 
cannot provide resources at all the RNC shall inform the CN accordingly. 
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8.2.2 S-MBMS Session Update procedure 



RNC 




CN 




[RANAP] MBMS SESSION UPDATE 






^ REQUEST 

[RANAP] MBMS SESSION UPDATE ^ 








RESPONSE 







Figure 8.5: S-MBMS Session Update procedure. Successful operation 

The S-MBMS Session Update procedure is initiated by the CN when an S-MBMS Session is ongoing and SGSN 
notices that there is a need to update the Ust of RAs. The MBMS SESSION UPDATE REQUEST contains the 
S-MBMS Service Id, List of RAs with PMM Idle UEs, etc.). 

8.2.3 S-MBMS Session Stop procedure 



RNC 




CN 




[RANAP] MBMS SESSION STOP 








REOUEST 
[RANAPl MBMS SESSION STOP 












RESPONSE 









Figure 8.6: S-MBMS Session Stop procedure 

This procedure is initiated by the CN to the RNCs with an ongoing S-MBMS session, when no more data will be sent 
for that S-MBMS service for some period of time. 

The S-MBMS Session Stop procedure also provides the S-MBMS lu Data Bearer Release functionality. 

8.2.4 RNC Registration procedure 



RNC 




CN 




[ 


RANAP] MBMS REGISTRATIO 


N 








, [ 


REQUEST 
RANAP] MBMS REGISTRATION 










RESPONSE 









Figure 8.7: S-MBMS Registration procedure 

This procedure is initiated by the RNC in the case that the RNC is not SRNC for any UE that has joined the S-MBMS 
Service, but this RNC is DRNC for PMM-CONNECTED UEs that have joined the S-MBMS Service and there is no 
S-MBMS Service Context for the S-MBMS Service in this RNC. 
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This procedure shall be initiated by the DRNC, as soon as a UE link is received over the lur and there exists no 
S-MBMS Service Context for the S-MBMS service for which the UE link is received. 



8.2.5 RNC De-Registration procedure 



RNC 




CN 




[RANAP] MBMS DE-REGISTRATION 






REQUEST 
[RANAP] MBMS DE-REGISTRATION 








RESPONSE 







Figure 8.8: RNC S-MBMS De-Registration procedure 

This procedure is initiated by the RNC towards the CN node it was registered to in case the RNC is not acting as a 
Serving RNC for any UE that has activated the S-MBMS Service and has ceased to act as a Drift RNC for UEs which 
has activated an S-MBMS service. 

8.2.6 CN De-Registration procedure 



RNC 




CN 




4 [R' 


^NAP] MBMS DE-REGISTRAT 


ON 






REOUEST 
[RANAP] MBMS DE-REGISTRATION ^ 








RESPONSE 







Figure 8.9: CN S-MBMS De-Registration procedure 

This procedure is initiated by the CN in order to inform the RNC that a certain S-MBMS Service is no longer available. 

8.2.7 S-MBMS CInannel Type Switclning over Uu 

Void. 

8.2.8 S-MBMS UE Uniting 



SRNC 



CN 



[RANAP] MBMS UE LINKING 
REQUEST 



[RANAP] MBMS UE LINKING 
RESPONSE 



Figure 8.10: S-MBMS UE linl<ing signalling flow 
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This signalling flow is only applicable for handling UEs in PMM-CONNECTED mode with activated S-MBMS 
Services. 

The signalling flow is used to link a specific UE to one or several S-MBMS service contexts in the SRNC. The MBMS 
UE LINKING REQUEST message contains the whole list of S-MBMS Service Ids activated by the UE. If there has not 
been a S-MBMS service context related to an S-MBMS Service Id then SRNC creates a S-MBMS service context as a 
result of this procedure. 



8.2.9 S-MBMS UE De-Linking 



SRNC 



CN 



[RANAP] MBMS UE DE-LINKING 
REQUEST 



[RANAP] MBMS UE DE-LINKING 
RESPONSE 



Figure 8.1 1 : S-MBMS UE De-linking signalling flow 

This signalling flow is only appUcable for handling UEs in PMM-CONNECTED mode with activated S-MBMS 
Services. 

The signalling flow is used to remove a specific UE from one or several S-MBMS service context in the SRNC. The 
MBMS UE DE-LINKING REQUEST message contains the list of S-MBMS Service Ids de-activated by the UE. 

8.2.10 S-MBMS Service Id Request 



UE 



RNC 



lu-cs connection establishment 



MSC 



RANAFJCOMMON ID 



[RANAPJMBMS SERV CE ID REQ 



[RANAP] MBMS SERVICE ID RESPONSE 



SGSN 



Figure 8.12: S-MBMS Service Id list over lu signalling flow 

This signalling flow is applicable for handling MBMS to UEs in RRC-Connected, PMM-IDLE state. The list of 
S-MBMS services the user has joined is sent over lu. 

The purpose of this signalling flow is to perform UE linking for a RRC connected, PMM idle user. The UE provides an 
indication that the user has joined at least one S-MBMS service and the PS Domain specific IDNNS (the message that 
would carry this information is FFS) whenever an lu-cs connection is established and the UE is PMM idle (that is there 
is no lu-ps connection). The RNC requests the S-MBMS services the UE has joined from the SGSN (or the SGSN the 
UE is attached to in case of lu-flex) using a connectionless procedure. The MBMS SERVICE ID REQ contains the 
IMSI of the UE. The SGSN response contains the full list of S-MBMS services the user has joined. 

The S-MBMS service list is then stored in the RNC. The list is deleted when the UE moves to RRC idle and the RRC 
context is removed in the RNC. 
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8.2.1 1 S-MBMS Attach/Detach over lur 

Void. 

8.2.12 S-MBMS Channel Type Reconfiguration over lur 

Void. 

8.3 S-MBMS Uu Signalling Flows 

8.3.1 Broadcast of S-MBMS System Information 



UE 



CRNC 



MBMS SYSTEM INFORMATION 



Figure 8.13: Broadcast of S-MBMS system information 

This signalling flow is applicable for handling S-MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is to broadcast S-MBMS system information to UEs using the BCCH. The MBMS 
SYSTEM INFORMATION shall be repeatedly transmitted after its first transmission. Upon receiving the first MBMS 
SYSTEM INFORMATION, the UE shall establish the radio bearer carrying an MCCH. 

The S-MBMS SYSTEM INFORMATION includes: 

• MCCH schedule information (access info, repetition and modification periods); 

• configuration of a radio bearer carrying an MCCH. 

More information may be included in the MBMS SYSTEM INFORMATION. 

8.3.2 S-MBMS Service Information 



UE 



CRNC 



MBMS SERVICE INFORMATION 



Figure 8.14: S-MBMS service information signalling flow 

This signalling flow is applicable for handling S-MBMS to UEs in PMM IDLE and PMM-CONNECTED mode. 
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The purpose of the signalling flow to inform UEs of all of S-MBMS services available in one spot/IMR cell. 
The MBMS SERVICE INFORMATION shall be transmitted periodically on MCCH to support mobility in the 
S-MBMS service. 

The MBMS SERVICE INFORMATION contains S-MBMS service ids and ptm indication. The S-MBMS service ids 
indicate the S-MBMS services which are being served in the spot/IMR cell or the S-MBMS services which can be 
served if the UE requests it. Ptm indication indicates that the S-MBMS service is on ptm in the cell, thus it informs the 
UE of the need of reception of the MBMS RADIO BEARER INFORMATION. More information may be included in 
the MBMS SERVICE INFORMATION. 

8.3.3 S-MBMS Radio Bearer Information 



UE 



CRNC 



MBMS RADIO BEARER INFORMATION 



Figure 8.15: S-MBMS radio bearer information signalling flow 

This signalling flow is applicable for handling S-MBMS to UEs in IDLE and PMM-CONNECTED mode. 

The purpose of the signalling flow is to inform UE(s) regarding the MTCH radio bearer information. MBMS RADIO 
BEARER INFORMATION shall be transmitted periodically on MCCH to support mobility in the S-MBMS service. 

MBMS RADIO BEARER INFORMATION includes S-MBMS Service Id, MBMS UTRAN Cell Group Identifier, 
logical channel, transport channel and physical channel information per S-MBMS service. An S-MBMS USRAN Cell 
Group Identifier is used to indicate to UEs which S-MBMS Cell Group the spot/IMR cell pertains to. More information 
may be included in MBMS RADIO BEARER INFORMATION. 

8.3.4 S-MBMS Access Information 



UE 



CRNC 



MBMS ACCESS INFORMATION 



Figure 8.16: S-MBMS Access Information signalling flow 

This signalling flow is applicable for handling S-MBMS UEs in IDLE mode. 

The purpose of the signalling flow is to inform UE(s) interested in a particular service of the potential need to transmit 
an SMS. The MBMS ACCESS INFORMATION is transmitted during counting and re-counting on MCCH. The 
MBMS ACCESS INFORMATION includes S-MBMS service id for each service for which counting is required and 
the associated access "probability factor". More information may be included in MBMS ACCESS INFORMATION. 
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8.3.5 S-MBMS Neighbouring Spot/IMR Cell Information 



UE 



CRNC 



MBMS NEIGHBOURING CELL 



Figure 8.17: S-MBMS Neighbouring Spot/IMR Cell Information signalling flow 

This signalling flow is applicable for handling S-MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the MBMS NEIGHBOURING CELL INFORMATION signalling flow is to inform UEs of the MTCH 
configuration of the neighbouring spots/IMR cells which are available for selective combining. In case of soft 
combining, the MBMS NEIGBOURING CELL INFORMATION contains the LI -combining schedule, which indicates 
when the soft combining is applicable between specific S-CCPCH of the spots/IMR cell and the specific S-CCPCH of 
the neighbouring spots/IMR cell. With MBMS NEIGHBOURING CELL INFORMATION the UE is able to receive 
MTCH transmission from neighbouring spots/IMR cell without reception of the MCCH of that spots/IMR cell. The 
MBMS NEIGHBOURING CELL INFORMATION shall be repeatedly transmitted on MCCH when selective or soft 
combining is utilized in the S-MBMS ptm transmission in the given spot/IMR cell group. 

8.3.6 S-MBMS Joined Indication 



UE 



SRNC 



MBMS JOINED INDICATION 



Figure 8.18: S-MBMS joined indication signalling flow 

This signalling flow is applicable for handling S-MBMS to UEs in RRC -Connected, PMM-IDLE state. The MBMS 
JOINED INDICATION is sent over the DCCH. 

The signalling flow is initiated by the UE after entering RRC-Connected, PMM-IDLE state. The purpose of the signalling flow 
is to enable the UE to inform the SRNC that the user has joined at least one S-MBMS service. The SRNC requests the S-MBMS 
services the UE has joined from the SGSN as defined in clause 8.2.10. 
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8.3.7 MTCH Scheduling Information 



UE 



CRNC 



MTCH SCHEDULING INFORMATION 



Figure 8.19: MTCH scheduling information 

This signalling flow is applicable for handling S-MBMS to UEs in PMM IDLE and CONNECTED mode. 

The purpose of the signalling flow is to enable UEs to perform discontinuous reception of MTCH. The UE may 
discontinuously receive MTCH based on scheduling information indicated by the MTCH SCHEDULING 
INFORMATION. This signalling is transmitted on MSCH mapped on SCCPCH carrying MTCH. The MTCH 
SCHEDULING INFORMATION is signalled on each MSCH repetition period. The MSCH repetition period and the 
offset from the MCCH modification period are indicated on MCCH. In case of soft combining, the repetition MSCH 
period is same for all soft combinable S-CCPCH. The scheduling information allows to cover different periods for 
different S-MBMS services. 

The MTCH SCHEDULING INFORMATION includes for each service: 

• S-MBMS service Id; 

• beginning and duration of S-MBMS data transmission; 

• duration can be infinite (no DTX). This option could be signalled in the MCCH; 

• indication of no S-MBMS data transmission for either this period or several consecutive periods (a period is 
expressed in MSCH repetition period). 



8.3.8 S-MBMS Change Information 



UE 



CRNC 



MBMS CHANGE 
INFORMATION 



Figure 8.20: S-IVIBIVIS change information 

This signalling flow is applicable for handling S-MBMS to UEs in PMM IDLE and CONNECTED mode. USRAN 
should transmit this signalling flow in beginning of each modification period on MCCH and repeat it at least in every 
repetition period of that modification period. UE shall read this information flow when detecting that MICH bits set for 
a service that UE has activated, or periodically at the begin of each modification period when receiving MTCH. 
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The purpose of the signalling flow is to indicate S-MBMS services whose MCCH information is changed in that 
modification period. The content of MBMS CHANGE INFORMATIO shall be minimized, so that the MCCH reading 
time for the UEs, activated S-MBMS service whose MCCH information is not modified on that modification period, is 
minimized. 

The MBMS CHANGE INFORMATION includes: 

• The S-MBMS service Ids for which MCCH information is modified on that modification period. 



9 Security for S-MBMS 

Void. 



1 Mobility Procedures for S-MBMS 

One of the requirements is: "Data loss during cell change should be minimal". Therefore, when the UE receiving an 
S-MBMS session in idle mode or connected mode (not including CELL_DCH) re-selects between spot/IMR cells, it 
should be possible to provide service continuity to this UE. 

The following mechanism has been identified to minimize the data loss on spot/IMR cell change. Additional 
mechanisms allowing to minimize data loss on long time loss of satellite signal are provided in NAS. 

10.1 Use of Periodical S-MBMS Channel Type Notification 

Void. 



1 0.2 UE Actions for Mobility 



The UE mobility between intra frequency spot/IMR cells is not affected by the S-MBMS reception. The mobility 
between different frequency layers is affected by the Frequency Layer Convergence process as defined in clause 1 1 .2, 
if used by the network. 

In CELL_FACH and in CELL_DCH state the RRC operation has priority over S-MBMS reception, thus UE performs 
the inter frequency and inter RAT measurements as configured by the SRNC. USRAN should utilize different 
periodicities between MCCH transmissions and CELL_FACH state measurement occasion, such that CELL_FACH 
state measurements and MCCH transmissions are not constantly overlapping for some UE. 

In Idle mode and in CELL_PCH, URA_PCH states the measurements are performed as configured by the network. The 
S-MBMS specific measurement occasions to S-CCPCH for UEs in idle mode and in CELL_PCH, URA_PCH states are 
not introduced and measurements have priority over S-MBMS reception. 

UEs may have DRx occasions for specific S-MBMS service when UE can stop decoding S-CCPCH and perform 
measurements. DRx occasion are based on scheduling information. UE may also have possibility to skip the complete 
MCCH transmission based on e.g. "value tag". 

When the UE reselects the spot/IMR cell due to the mobility or returns to on service from out of service, the UE shall 
acquire the MCCH information if the interested S-MBMS service is available in the selected spot/IMR cell for the 
reception of the service. The service is available when the session has been already started and the service is being 
served in the spot/IMR cell, or the service can be served in the spot/IMR cell if the UE requests it. 

If the S-MBMS service is available in the spot/IMR cell, the UE will perform an action for the service reception in the 
spot/IMR cell. The UE, which moves to the new spot/IMR cell, will operate according to the RRC state/mode as 
follows. 
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Whenever the UE moves between ptm cells, UE shall receive an MBMS UCG-Id, which is included in the MBMS 
RADIO BEARER INFORMATION. If the MBMS UCG-Id received in a new spot/IMR cell is the same as the MBMS 
UCG-Id received in an old spot/IMR cell, then the UE receives MTCH without re-establishment of its PDCP as the new 
spot/IMR cell is processed by the same PDCP entity as the old spot/IMR cell. If the MBMS UCG-Ids differs between 
old on new spot/IMR cell, the UE re-establishes its PDCP entity according to the RADIO BEARER INFORMATION. 
In case that RLC entity is shared in CRNC between old and new spot/IMR cell, the UE receives MTCH without 
re-establishment of its RLC. If old and new spot/IMR cell does not share RLC entity in CRNC the UE shall re-establish 
its RLC. UE shall re-establish MAC and physical layer protocol entities upon spot/IMR cell change. 

10.2.1 RRC idle mode 

Idle mode UE shall: 

• if BCCH contains information regarding the MCCH in the new spot/IMR cell: 

listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

if the MBMS SERVICE INFORMATION contains the interested S-MBMS service-id: 

receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 

if the UE receive the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION; and 

if MBMS RADIO BEARER INFORMATION contains the interested S-MBMS service id: 

listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.2 URA_PCH State 

URA_PCH state UE shall: 

• perform URA update procedure if needed; 

• if BCCH contains information regarding the MCCH in the new spot/IMR cell: 

listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

if MBMS SERVICE INFORMATION contains the interested S-MBMS service id: 

receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 

if the UE receive the MBMS RADIO BEARER INFORMATION before MBMS SERVICE 
INFORMATION message; and 

if MBMS RADIO BEARER INFORMATION contains the interested S-MBMS service id: 

listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.3 CELL_PCH 

CELL_PCH state UE shall: 

• perform spot/IMR cell update procedure; 

• if spot/IMR cell update confirm message contains S-MBMS radio bearer information: 

listen to the S-MBMS radio bearer; 

• else: 

if BCCH contains information regarding the MCCH in the new spot/IMR cell: 
hsten to the MCCH and receive the MBMS SERVICE INFORMATION; 
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if MBMS SERVICE INFORMATION contains the interested S-MBMS service id; and 

receive the MBMS RADIO BEARER INFORMATION message and hsten to the MTCH; 

if the UE receives the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION; and 

if MBMS RADIO BEARER INFORMATION contains the interested S-MBMS service id: 

listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.4 CELL_FACH 

CELL_FACH state UE shall, depending on UE capability: 

• perform spot/IMR cell update procedure; 

• if spot/IMR cell update confirm message contains S-MBMS radio bearer information: 

listen to the S-MBMS radio bearer; 

• else: 

if BCCH contains information regarding the MCCH in the new spot/IMR cell: 

listen to the MCCH and receive the MBMS SERVICE INFORMATION; 

if MBMS SERVICE INFORMATION contains the interested S-MBMS service id; and 

receive the MBMS RADIO BEARER INFORMATION and listen to the MTCH; 

if the UE receives the MBMS RADIO BEARER INFORMATION before the MBMS SERVICE 
INFORMATION; and 

if MBMS RADIO BEARER INFORMATION contains the interested S-MBMS service id: 

listen to the MTCH without the need of receiving the MBMS SERVICE INFORMATION. 

10.2.5 CELL_DCH State 

CELL_DCH state UE shall: 

• act on the RRC message received on DCCH in handover. 



1 1 Resource Management for S-MBMS 
11.1 S-MBMS Access Control Procedure 

MCCH messages initiating counting or recounting cause multiple responses from UEs within a spot/IMR cell. This may 
result in RACH congestion if number of UEs is high in a spot/IMR cell. To avoid this, CRNC may perform S-MBMS 
access control procedure during counting or recounting procedure. 
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3. UE in Idle mode request 

RRC connection based on the 

initial probability factor 1 

UE in URA/CELL_PCH or 

CELL_FACH state response 

counting based on the initial 

AfobabiJIty factor 2 



4. Detecting the needs for 
updating 
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7. UE in Idle mode request RRC 

connection based on the updated 

probability factor 1 

UE in URA/CELL_PCH or CELL_FACH 

state response counting based on the 

updated probability factor 2 



Figure 11.1: S-MBMS Access Control Procedure 

1) CRNC calculates an initial probability factor for a S-MBMS service when a MCCH message causing counting 
or recounting is about to be sent. 

2) CRNC includes the probability factor into the MCCH message and sends it to UEs. This can be done in 
S-MBMS Group Notification. 

3) UEs perform SMS transmission procedure using the probability factor received in step 2. UEs keep listening to 
MCCH to get updated probability factor until they succeed to transmit SMS. 

4) CRNC detects the probability factor needs to be updated. 

5) CRNC recalculates the probability factor. 

6) CRNC includes the updated probability factor into the MCCH message and sends it to UEs. 

7) UEs perform SMS transmission procedure using the new probability factor. UEs keep listening to MCCH to 
get updated probability factor until they succeed to transmit SMS. 

CRNC and UEs who are still trying to perform the SMS transmission procedure repeat step 3 to step 7 until 
e.g. counting or recounting procedure ends. 



1 1 .2 Frequency layer Convergence 



Frequency Layer Convergence denotes the process where the USRAN requests UEs to preferentially re-select to the 
frequency layer on which the S-MBMS service is intended to be transmitted. This layer preference could be done by an 
additional S-MBMS session related Layer Convergence Information (LCI) such as offset and target frequency. The 
FLC is supported by specifications for both networks utilizing HCS and for networks not utilizing HCS. 

The Preferred Layer (PL) is indicated per S-MBMS service and the LCI (offset) is the same for all S-MBMS services 
on a given preferred layer. USRAN can consist of multiple preferred layers and the PL for given services is decided by 
RRC. Thus the PL for an S-MBMS service might be different in different parts of the service area (case of service over 
several spot coverage areas). 
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The LCI can be signalled to UEs by the CRNC after the session start is received over lu interface until reception of the 
session stop. The UEs shall take LCI into account whenever it is signalled on the MCCH in Idle mode and URA_PCH, 
CELL_PCH and in CELL_FACH states. The PLC is not applicable in CELL_DCH state, as it is only effecting UEs cell 
re-selection procedure. 

The UE shall ignore Sintersearch parameter only for the potential preferred layers when LCI is signalled and on 
preferred layer the UE shall apply the Sintersearch parameter. In case of UE is in CELL_FACH state without 
measurement occasions, the UE may not be able to measure spot/IMR cells on preferred layers. 

In the case that the UE has joined multiple services and they have different frequencies as preferred layer, the UE 
should apply the PLC applicable for the highest priority S-MBMS service, which it has activated. The priority setting of 
different S-MBMS services is decided by NAS. 

Based on RRC decision, a given S-MBMS service can be provided on non-preferred layer. 



1 1 .3 Frequency Layer Dispersion 



Frequency Layer Dispersion (FLD) denotes the process where the USRAN redistributes UEs across the frequencies. 
USRAN can use FLD per S-MBMS session. 

The request to perform dispersion can be signalled to UEs by the CRNC after the session stop is received over lu 
interface. The UEs shall take into account this request whenever it is signalled on the MCCH. 

The FLD is applicable in Idle mode, URA_PCH, CELL_PCH and CELL_FACH states. 

When FLC is applied, the UE stores the frequency where it was camped previously. Upon session stop, the UE attempts 
to return to that frequency. 

If the UE does not find a suitable cell on the target frequency, the UE attempts to select a cell on a randomly chosen 
frequency. 

Dispersion does not apply in the case where the UE decides to receive another service for which FLC is applied. 
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Annex A (informative): 
Bibliography 



• IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and 
uncompressed". 
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